An interesting problem arose in writing this stack, because one of the new features of HyperCard 2.0 is that background fields can have SharedText. It turns out that this makes snooping to see whether a background field has any text quite a complicated job. This is because every background field can have Shared text and non-Shared text simultaneously and with no regard for whether the SharedText property of the field is True at any given moment. So, in checking or collecting the text of a background field, the stack has to look at the field twice: first, it sets the SharedText property of the field to True, and looks to see if it has text; then, it sets the SharedText property of the field to False, and now it has to look at every card of that background to see if the field has text on that card. Quite an interesting little dance... Note that this means that the stack has to change a feature of the stack being analysed; but donΓÇÖt worry, it resets the property the way it found it.
I have often been asked ΓÇö okay, one guy asked me once ΓÇö whether the creation of the ancillary textfiles is really necessary. In theory, it is not; but right now, it is. There is an absolute limit on the number of characters a field can hold; and there is a memory-dependent limit, which it would be unwise to press, on the number of characters a variable can hold. The limit on the size of a file on disk, on the other hand, is far less likely to be approached. The program therefore writes its results to disk ΓÇö and there they must stay, alas, since I do not have an XCMD that allows the user to delete a non-stack from within HyperCard. To allow you to see those results, then, even though their size may exceed the capacity of a scrolling field, the program allows you a crude sort of super-scrolling: if a textfile is too large to fit into the scrolling field, the program imports only the first 27,000 or so characters, and two new buttons appear, to allow you to see the next chunk, or start at the first chunk again:
 
There are certainly other ways to get around the problem than by the use of a textfile: for example, one might simply create enough scrolling fields to hold all the information. But I have not thought it worth while to implement such a device in this release; and the reason for this is that one of the chief advantages of a textfile is that you can print it. In theory, itΓÇÖs true, you could print everything in a scrolling field, direct from HyperCard, which would be more convenient; but I have found that (on my computer, at least) a bug in HyperCard 2.0 causes printing to an ImageWriter to stop after exactly 5 pages, which is often not enough to print the whole field. If this bug is ever fixed, I will probably write a new version in which the user is given the option of not generating any textfile at all.
